Modern wired and wireless data networks are increasingly susceptible to interception and forgery of communications. These data security issues are particularly pronounced in short-range wireless network environments—such as those defined by the IEEE 802.11b, Bluetooth, and HiperLAN2 standards—because it is possible for nearby intruders to intercept radio transmissions. With wireless networks providing a transmission range of tens or even hundreds of meters, the ease of data intrusion is quite pronounced. Given the insecurity of radio transmissions, encryption is required for data sent and received within a wireless environment.
A wireless LAN environment comprises a plurality of wireless access points, each of which bridges traffic between a radio interface and a wired LAN interface. A large wireless network installation may include many such access points. Each access point is typically connected to an edge router that separates the wireless and wireline networks (see, for example, an access point “adapter” as described in the second related invention); alternatively, the edge router may be co-located with the access point, forming a “Handoff Management Point” as described in the first related invention. (References hereinafter to edge routers apply equally to either case.) For the wireless network, the edge routers provide various services, which may include network address assignment, support for mobility across access points and subnets, authentication and access control, device location tracking, and so on. Within this environment, users may move between different access points, either because they are mobile or because of ambient changes to the radio transmission patterns within the network environment. To deliver consistent connectivity across all access points, the various edge routers may share a single Internet Protocol (“IP”) address which is exposed on their wireless interfaces (that is, to nodes communicating with the edge router from or through the wireless access points). (For example, one or more “connectivity groups” might be defined, each comprising one or more edge routers, where all the edge routers in a particular connectivity group share an IP address on their wireless interfaces.) In addition, each edge router has a unique “external” IP address that is exposed on its wireline interface (that is, to nodes communicating with the edge router from the external network); these “external” IP addresses are used to direct traffic to a particular edge router.
Several prior art technologies exist for addressing issues of data security in wireless environments, but many of these are known to be insecure. In wireless LAN environments, the Wired Equivalent Privacy (“WEP”) protocol provides for device authentication and data encryption. However, a number of papers have been written which document serious flaws in the encryption technology of this protocol.1 The Bluetooth encryption standard also has documented flaws.2 1See the following papers for a sampling of this documentation:J. R. Walker. “Unsafe At Any Key Size: An Analysis of the WEP Encapsulation” Intel Corporation (document IEEE 802.11-00/362), 20 Oct. 2000.W. A. Arbaugh. “An Inductive Chosen Plaintext Attack Against WEP/WEP2.” IEEE 802.11 TGi Working Group, Orlando, Fla., May 2001. (A complete analysis is described in W. A. Arbaugh, N. Shankar, Y. C. Wan, “Your 802.11b Network has no Clothes,” March 2001.)N. Borisov, I Goldberg, and D. Wagner. “Intercepting Mobile Communications: The Insecurity of 802.11.” Proceedings of the ACM SIGMOBILE Seventh Annual International Conference on Mobile Computing and Networking, July 2001.N. Borisov, I Goldberg, and D. Wagner. “Intercepting Mobile Communications: The Insecurity of 802.11.” Proceedings of the ACM SIGMOBILE Seventh Annual International Conference on Mobile Computing and Networking, July 2001.S. Fluhrer, I. Mantin, and A. Shamir. “Weaknesses in the Key Scheduling Algorithm of RC4.” Proceedings of the Eighth Annual Workshop on Selected Areas in Cryptography, August 2001.A. Stubblefield, J. Ioannidis, and A. Rubin. “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP.” AT&T Labs Technical Report TD-4ZCPZZ, Revision 2, 21 Aug. 2001.                2See the following paper: IT Week. “Tests Uncover Bluetooth Flaw.” ZDNet, 8 Sep. 2000.        
Other prior art systems such as Virtual Private Networks (VPNs) can provide good data security. However, this technology is designed such that it enables a secure point-to-point link between a client and a server. To deploy a VPN, each client must establish a VPN session with a VPN server (also known as a VPN gateway). To ensure the security of transmitted data traffic, a VPN is typically configured so that all network traffic from the client must be encrypted and pass through that VPN server, regardless of its ultimate destination; all traffic to that client similarly must pass through that VPN server and be encrypted, regardless of its origin. This VPN configuration has a number of drawbacks. First, the VPN server represents a bottleneck because it must process all traffic traveling to or from the client. Second, it introduces considerable network bandwidth and network switching overhead because all packets must be routed through the VPN server (instead of being routed directly between the client and its peer host). Third, it introduces considerable configuration and management overhead because each client must be appropriately configured with the correct VPN server identity, and changes to the VPN servers require corresponding changes to the various client configurations. It is possible for a client to communicate with multiple VPN servers simultaneously, with each server configured to handle traffic associated with a particular set of peer hosts. However, a multi-server system requires even more configuration and does not eliminate the fundamental bottlenecks, routing, bandwidth, and management complexities that are inherent to a VPN design. Consequently, it is not feasible to deploy VPNs in a modern clustered or distributed server architecture, even though this deployment is desirable for reasons of flexibility, redundancy, and/or scalability.
The result is that in environments such as wireless local area networks (for example, IEEE 802.11b networks or Bluetooth networks) and Virtual Private Networks, a choice must be made between good security on the one hand and good scalability or reliability on the other—because as just discussed, the VPN architecture which is preferred for security in these environments is very difficult to deploy in a clustered or distributed manner.
The most common VPN implementation uses a security protocol known as Internet Protocol Security (“IPsec”). IPsec is defined in Internet Engineering Task Force (“IETF”) Request for Comments (“RFC”) 2401, “Security Architecture for the Internet Protocol” (November 1998), referred to hereinafter as “the IPsec specification”. IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more “paths” between a pair of hosts and/or routers. Within a VPN architecture, IPsec provides the data security required to protect traffic between the VPN client and the VPN server.
IPsec has two principal modes, “tunnel mode” and “transport mode.” Tunnel mode is generally used between end nodes and routers, or between pairs of routers; it protects data communications across one or more network links that are not believed to be secure, but the same communications may traverse other portions of the network unprotected. Transport mode is generally used between end nodes; it protects traffic across the entirety of the network between the two nodes. Most VPN implementations employ IPsec in tunnel mode.
The protocols used for encrypting and authenticating data in the IPsec architecture are “Encapsulating Security Payload” (“ESP”) and “Authentication Header” (“AH”), respectively. (For more information on these protocols, refer to IETF RFC 2406, “IP Encapsulating Security Payload”, November 1998, and IETF RFC 2402, “IP Authentication Header”, November 1998.) These protocols require selection of a cipher and key negotiation, as well as negotiation of various other parameters, before they can be used for communication. This choice of cipher, keys, and other information for a particular instance of the AH or ESP protocol between two nodes forms what is known as a Security Association (“SA”). The IPsec protocol uses a key-exchange protocol known as Internet Key Exchange (“IKE”) to negotiate the Security Associations for the ESP and AH protocols. The first attempt to transmit data from one node to another using ESP or AH triggers an IKE negotiation, which leads to both nodes agreeing on an SA. Each SA pertains to communications between the two nodes, as identified by their IP addresses; on each node, a particular SA is distinguished from the SA(s) for other communications by the IP addresses representing the two endpoints of the IPsec session and by a locally assigned SA number.
It should be noted that an SA may include not only the initial information negotiated by the key-exchange protocol but also cryptographic information relevant to previous messages protected by ESP or AH (such as block-chaining or feedback information for a cipher or message authentication code) which is required to correctly process new ESP or AH messages. This additional cryptographic information may change as the IPsec tunnel is used, in accordance with the procedures of the negotiated cipher.
In wireless environments in which the radio link is deemed to be insecure, it is particularly desirable to use IPsec in tunnel mode to protect traffic between wireless end nodes and the edge routers separating the wireless from the wired portion of a given network. As described above, a large wireless network includes multiple wireless access points and edge routers; to achieve transparency, several edge routers may share the same IP address on their wireless interfaces. Because IPsec is designed to support point-to-point encryption sessions, however, it is not well suited to a distributed or clustered architecture that can deliver reliability and scalability, as will now be described.
A particular difficulty for a distributed or clustered IPsec implementation is distribution of cipher keys. Two serious problems arise. First, for IKE negotiation to succeed, all of the IKE packets for establishing the SA must arrive at the same physical node (e.g. edge router); otherwise no SA will be negotiated and no encrypted traffic can ever be exchanged. This presents a problem with mobile devices, which may be passed from one edge router to another during the time that an IKE negotiation process is underway. Second, once IKE negotiation has produced one or more SAs, those SAs must be made available to every node (e.g. edge router) that can transmit or receive traffic using the associated IP address. That is, the SAs (and their associated cipher keys, ESP parameters, and AH parameters) need to be available at any edge router to which a mobile wireless end node's traffic is directed, in order for the collection of edge routers to provide seamless yet secure connectivity for the mobile end node. Otherwise, packets may arrive at nodes at which they cannot be decrypted/encrypted or authenticated, resulting in severe problems including significant packet loss and communication breakdown, and in turn, an increase in network latency and a decrease in network throughput.
Accordingly, a need exists for enhanced security in wired and wireless networks while maintaining scalability, reliability, and performance.